home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000123_connolly@pixel.convex.com _Mon Jun 8 22:52:36 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  3KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA12426; Mon, 8 Jun 92 22:52:36 MET DST
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA27128; Mon, 8 Jun 92 22:50:38 +0200
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA03927; Mon, 8 Jun 92 15:50:19 -0500
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA15921; Mon, 8 Jun 92 15:50:17 -0500
  10. Message-Id: <9206082050.AA15921@pixel.convex.com>
  11. To: mitra@pandora.sf.ca.us ()
  12. Cc: wais-talk@think.com, www-talk@nxoc01.cern.ch
  13. Subject: Re: MIME for global hypertext 
  14. In-Reply-To: Your message of "Mon, 08 Jun 92 13:11:15 PDT."
  15.              <9206081311.aa26440@pandora.sf.ca.us> 
  16. Date: Mon, 08 Jun 92 15:50:17 CDT
  17. From: Dan Connolly <connolly@pixel.convex.com>
  18.  
  19.  
  20.  
  21. >My question is on a fairly minor point of your document, you mention that 
  22. >a MIME document typically consists of a content and then the pointers, 
  23. >with the hypertext links being references to the pointers.
  24.  
  25. Well, this is not typical, but it's the model I'm proposing for
  26. hypertext. Typically MIME message bodies are either single part
  27. text/image/audio, or multipart. The standard multipart types
  28. are mixed, meaning "show these one after the other," parallel,
  29. meaning "show these at the same time," or alternative, meaning
  30. "these all represnt the same info. Take your pick."
  31.  
  32. The "content and then list of pointers [or attachments]" model
  33. is my own proposed format for hypertext.
  34.  
  35. >  In Wais, it 
  36. >is quite possible to return part of a document (by byte position), and 
  37. >if the pointers are part of the document itself then they may not be 
  38. >returned at the time the user chooses to try and follow a link? 
  39. >
  40. I would suggest that the WAIS server interpret the byte positions
  41. as offsets into the content part of the hypertext. So the structure
  42. remains in tact. Byte offsets into a MIME multipart message
  43. don't mean much. Transport systems may mess with the headers and
  44. trailing whitespace on body lines. Line offsets may be meaningful
  45. inside text body parts, as long as none of the lines have to be
  46. split due to line length constraints.
  47.  
  48. Keep in mind that this multipart structure is only necessary for
  49. hypertext (i.e. contains links) and hypermedia (i.e. contains
  50. multimedia attachments) documents.
  51.  
  52. Traditional documents can be simple single part bodies. For example,
  53. A plain text file starting with a new-line will be interpreted as
  54. a body part with no headers, which defaults to the type
  55. "text/plain; charset=US-ASCII" ,i.e. plain old text.
  56.  
  57. >My concerns are around doing these things for users on low-speed (2400 baud)
  58. >modems....